optimization info/backend updates #853
Conversation
* Placing NLopt support into a submodule will make it easier to move NLopt to an extension and promote PRIMA to the default backend. * Unfortunately, the profiling code still has been explicit assumptions around NLopt.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #853 +/- ##
==========================================
- Coverage 96.27% 95.49% -0.79%
==========================================
Files 38 38
Lines 3654 3708 +54
==========================================
+ Hits 3518 3541 +23
- Misses 136 167 +31
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ats/MixedModels.jl into pa/optimizer-backend-abstraction
…ats/MixedModels.jl into pa/optimizer-backend-abstraction
Minor changes in grammar.
There was a problem hiding this comment.
This looks very good. Thanks for your careful attention to detail.
I am beginning to think that my plan to change the fitlog to a TypedTables.Table or a Tables.MatrixTable might be more complicated than it is worth. The motivation was to use a single vector to store the information from the evaluations; push!ing the objective and merge!ing the parameter vector onto the end after each evaluation. That would save creating the tuples of parameter vectors and objective values. In retrospect I don't think it would be that much of a win and the implementation is rather complex.
Instead I will keep the fitlog struct as it is and add an optional extractor that does the conversion.
Uh oh!
There was an error while loading. Please reload this page.